Organizations that employ computer resources commonly require users to authenticate their identities before the organizations grant the employees access to the resources. For example, a company may require its employees to logon to an authentication server and enter credentials, such as usernames, passwords, and/or PINs (Personal Identification Numbers). The authentication server grants access only if it can verify the credentials.
Many organizations require users to enter token codes in addition to other credentials. For example, a company may issue its employees hardware tokens. Hardware tokens are generally simple devices, which have no network connections and cannot run user software. Hardware tokens automatically generate and display token codes at regular intervals, such as once per minute. The token codes produced by a hardware token may be based on a unique seed (e.g., a 256-bit value) which has been provisioned to the hardware token and thus to the specific user to whom the token is issued. The hardware token is typically a portable device (e.g., a key fob), which includes a timer and applies an algorithm to update the token code each time the timer expires. At the authentication server, the same seed is maintained, and the authentication server may apply the same or an equivalent algorithm as is applied on the hardware token, such that the token code produced by the authentication server can track the token codes produced by the hardware token. An example of a hardware token is the SecurID®, which is available from RSA The Security Division of EMC, of Bedford, Mass.
Organizations may also issue software tokens. Software tokens are programs that can be run on user devices, such as laptops, smart phones, or tablet computers, for example. Software tokens and hardware tokens work in similar ways, except that software tokens run on user devices and thus do not require special hardware.
To perform authentication with a token (either a hardware token or a software token), a user may be directed to a login screen, where the user is prompted to enter a user ID, the currently displayed token code, and (optionally) other credentials. The user then submits an authentication request, which sends the entered credentials to the authentication server. The authentication server receives the authentication request and computes an expected value of the token code, based on the seed it stores for the received user ID and the time. If the expected value of the token code matches the token code received from the user, and any other supplied credentials are verified, then the authentication server may grant the user access to the organization's resources. Otherwise, the authentication server may deny access.